… boot options (OpenDevicePartnership#1272)

## Description

Add hotkey detection support to the boot orchestrator, allowing
platforms to configure
alternate boot options that are used when a hotkey (e.g., F12) is
pressed during boot.

Changes:
- Add `detect_hotkey()` helper function to check for hotkey press via
SimpleTextInput protocol
- Add `hotkey_devices` field and `with_hotkey_device()` builder to
`BootOptions`
- Update `BootOrchestrator` to use alternate boot options when hotkey is
detected

---

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [x] Includes tests?
- [ ] Includes documentation?

## How This Was Tested

- Unit tests for `detect_hotkey()` (no input handles case)
- Unit tests for `hotkey_devices` config (single device, multiple
devices, combined with hotkey)
- `cargo test -p patina_boot` passes

## Integration Instructions

Platforms can configure hotkey boot options:

```rust
BootOptions::new()
    .with_device(primary_device)
    .with_hotkey(0x16) // F12 scancode
    .with_hotkey_device(alternate_device)
```

Closes OpenDevicePartnership#1228

…e_system_table (OpenDevicePartnership#1284)

Release SYSTEM_TABLE lock (TPL_NOTIFY) before accessing
ComponentDispatcher (TPL_APPLICATION) to avoid TPL violation.

PR OpenDevicePartnership#1225 lowered ComponentDispatcher from TPL_NOTIFY to TPL_APPLICATION
to allow components to use boot services, but this created a conflict
when initialize_system_table held SYSTEM_TABLE while setting
boot/runtime services on ComponentDispatcher.

Fix: Extract boot/runtime services pointers while holding SYSTEM_TABLE
lock, then release it before accessing ComponentDispatcher.

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?

- Unit tests pass
- QEMU Q35 boots without TPL violation panic

N/A

…ion (OpenDevicePartnership#1290)

Add support for expanding partial (short-form) device paths to full device paths by matching against the device topology.

- Add `is_partial_device_path()` to detect partial paths (start with
Media/Messaging nodes instead of Hardware/ACPI)
- Add `expand_device_path()` to find matching full paths by enumerating
device handles
- Wire expansion into `boot_from_device_path()` for transparent handling
- Currently supports HardDrive nodes with GPT partition signature
matching

This enables booting from Boot#### variables containing partial device paths like `HD(1,GPT,<GUID>)\EFI\BOOT\BOOTX64.EFI`.

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [x] Includes tests?
- [ ] Includes documentation?

- Unit tests for `is_partial_device_path()`, `expand_device_path()`, and
signature matching
- `cargo test -p patina_boot` passes (32 tests)
- QEMU Q35 platform test passes

N/A

Closes OpenDevicePartnership#1280

…stration design (OpenDevicePartnership#1333)

## Description

Refactors `patina_boot` from a monolithic `BootOrchestrator` component +
`Config<BootOptions>` pattern to a trait-based design:

- **`BootOrchestrator` trait** — defines the boot flow interface with
`execute() -> Result<!, EfiError>`, enforcing at the type level that
successful boot never returns
- **`BootDispatcher`** — the Patina component that installs the BDS
architectural protocol and delegates to a `BootOrchestrator`
implementation
- **`SimpleBootManager`** — a default `BootOrchestrator` implementation
for platforms with straightforward boot topologies
- **`BootConfig`** — unified boot configuration (replaces previous
`BootOptions` + `SimpleBootConfig` split), requires at least one device
at construction (compile-time enforcement)

Also updates `helpers.rs` imports from removed
`uefi_protocol::device_path` to
`device_path::paths`/`device_path::node_defs`.

`patina_dxe_core` changes (image handle plumbing) split out to OpenDevicePartnership#1374.

- [x] Impacts functionality?
- [ ] Impacts security?
- [x] Breaking change?
- [x] Includes tests?
- [ ] Includes documentation?

## How This Was Tested

1. Unit tests: 35 pass (`cargo test -p patina_boot`)
2. Integration tested on QEMU Q35 — all components dispatched, BDS phase
ran, boot options attempted, failure handler fired correctly
3. CI: fmt, clippy, all platforms pass

## Integration Instructions

Update boot orchestration usage from:
```rust
use patina_boot::{component::BootOrchestrator, config::BootOptions};
// In configs():
add.config(BootOptions::new()...);
// In components():
add.component(BootOrchestrator);
```

To:
```rust
use patina_boot::{BootDispatcher, SimpleBootManager, config::BootConfig};

add.component(BootDispatcher::new(SimpleBootManager::new(
    BootConfig::new(primary_device_path())
        .with_device(fallback_device_path())
        .with_hotkey(0x16)
        .with_hotkey_device(usb_device_path())
        .with_failure_handler(|| { /* ... */ }),
)));
```

…penDevicePartnership#1375)

## Description

Rewrite `discover_console_devices()` from a stub into a full
implementation that enumerates console protocol handles, builds
multi-instance device paths, and writes `ConIn`, `ConOut`, and `ErrOut`
UEFI global variables via `SetVariable`.

- Adds `EFI_GLOBAL_VARIABLE` GUID to `patina::guids`
- Adds `build_multi_instance_device_path()` helper for constructing
multi-instance device paths from protocol handles
- Updates `is_partial_device_path()` to recognize FV/FvFile paths as
non-partial
- Includes get_variable readback verification with device path display
logging

Depends on OpenDevicePartnership#1333. Closes OpenDevicePartnership#1230

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?

## How This Was Tested

Verified on QEMU Q35 with VGA enabled. Console variables written and
read back successfully:
- ConIn: 24 bytes (SimpleTextInput)
- ConOut: 60 bytes (SimpleTextOutput + GOP)
- ErrOut: 30 bytes (SimpleTextOutput)

## Integration Instructions

N/A

…with DxeServices (OpenDevicePartnership#1422)

## Description

Interleave controller connection with DXE driver dispatch during device
enumeration. Connecting controllers can discover new firmware volumes
(e.g., PCI option ROMs) that contain drivers for devices behind that
controller. Those drivers must be dispatched before the next round of
enumeration, otherwise the devices they serve will not be found.

`SimpleBootManager` uses `interleave_connect_and_dispatch()` to
alternate
between connecting controllers and dispatching newly-discovered drivers
until both stabilize. The `DxeDispatch` service trait (from OpenDevicePartnership#1421) is
consumed via dependency injection.

Note: `interleave_connect_and_dispatch()` currently uses `connect_all()`
which connects every controller on every round. This is functional but
inefficient for platforms with large device topologies — a future
optimization could connect only newly-discovered controllers.

- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [x] Includes tests?
- [ ] Includes documentation?

## How This Was Tested

- Built SBSA DXE core binary with `BootDispatcher` + `SimpleBootManager`
replacing TianoCore BdsDxe
- Booted Windows ARM64 under QEMU SBSA-ref emulation with Patina BDS
handling the full boot flow
- Verified interleaving: controller connection discovered AHCI device,
partial device path expanded to full path, Windows bootloader loaded,
ExitBootServices completed

## Integration Instructions

Depends on OpenDevicePartnership#1421 (`DxeDispatch` service trait) for platform binary
integration.

Remove TianoCore `BdsDxe.inf` from platform DSC/FDF since the
`BootDispatcher` provides the BDS architectural protocol.